會選擇在 distributed(分散式)之前先討論 consistency(一致性)，是由於如果我們的分散式系統所提供的服務無法保有一定程度的正確性的話，不論可以回應多大量或多快速的請求都是沒有意義的，而且可能會是一場巨大的災難。一般來說我們會討論到 data consistency，是基於複數存取實體因為時間差或實體間同步異常中斷，而產生的資料或狀態不一致，而單一 server 內因為多併發而產生的資料不一致屬於 data race 範疇，我們在後面一點的文章另外討論。

情境

試想大型電商如今天如果將所有庫存清單都放在單一實體，如何能夠應付全球每秒數以萬計的存取，故勢必有 replica 的存在，而各地的存取可能透最常見的 master 寫入 slaves 讀取的方式實作，也可能是透過叢集式資料庫系統用過半寫入的方式進行。

Strong Consistency

所有讀取都在同一實體便是 strong consistency (強一致性) 的代表，可以確保每次存取都是當下最新的值，但單一實體系統有其負載上限，如果電商大如 Amazon 其服務的客戶之多，是不可能提供使用者能滿足的可用性的。

Eventual Consistency

將讀寫分離屬於大家最常見 eventual consistency (最終一致性) 的實現方式，每位用戶分別讀取 slave replica 看到的商品數量可能略為不同，但下單確認請一致送到 master 進行，確保寫入的時候符合 atomicity (原子性)，如此一來不論用戶的交易成功或失敗都可以保證最終 master 的商品數量是正確的，且 slave 透過同步的方式最終也能呈現一致的商品數量。

取捨

其實在上面電商的例子僅以用戶的角度，觀察到我們捨棄讀取時的一致性，目的是為了提高系統的整體可用度，但如果是不同的角度需要取捨的面向也有所不同，下一次將介紹著名的 CAP 理論提供我們在取捨時思考我們想滿足的需求適合的取捨。